1. Technical Field
The invention is related to the generation and display of toolbars on a display screen, and more particularly to a system and process for generating and displaying a dynamically adjustable toolbar that optimizes the number and configuration of the toolbar buttons that are displayed in view of the amount of space allotted for the toolbar on the display screen.
2. Background Art
Toolbars are a standard graphical user interface (GUI) element employed in most current software applications. Generally, a toolbar appears to the user as a single row or column of icons on a computer monitor screen, although sometimes a toolbar will have multiple rows or columns of icons. The icons represent various program functions or commands. The user typically interacts with a toolbar by using a pointing device of some type such as a computer mouse to place a cursor displayed on the monitor screen over an icon contained in the toolbar. The user then selects the function or command represented by the icon, such as by clicking the left-hand mouse button. In addition to the icons, text elements in the form of labels are often disposed adjacent to the associated icon. Typically, the label either appears underneath its icon or to the right of the icon. The labels usually identify the function of the associated icon. In that case, the label remains static. For example, the label might read xe2x80x9csavexe2x80x9d, thus identifying the associated icon as representing the save function. The save label would not change. However, the label can also be used to indicate a current state of a function represented by an associated icon. For example, a toolbar icon might represent a category assignment function. This function is often used in personal information management (PIM) programs to categorize an entry as business related or personal. The label associated with the category assignment icon would indicate the currently selected category (e.g., business or personal). Thus, rather than identifying the function of the associated icon, the label indicates its current state. This type of label is not static and will change depending on the selected state of the function represented by the icon. In many current applications the toolbar can be configured to display both the icon and label, the icon only, or the text only. It is noted that the icon and related label combination is often referred to as a toolbar button. However, sometimes an icon without a label is also referred to as a button.
A toolbar is usually associated with an application window typically displayed on a portion of the computer screen. These application windows are graphic user interfaces that are used to present information to a user and to facilitate interaction between the user and the application program associated with the window. When a toolbar is visually attached to a particular application window, it length will be restricted to the size of the window, or even less if the toolbar is allowed to only appear in a portion of the window. Thus, if the toolbar appears as a horizontal row in the window, its length is limited by the width of the window or the width of the portion of the window in which the toolbar is allowed to appear. Likewise, when the toolbar appears as a vertical column in the window, its length will be restricted to the height of the window or some portion of the height. These restrictions on the length of a toolbar limit the number of buttons that can be included in the toolbar. Granted, the icons and labels making up the buttons could be made smaller to fit more in the available toolbar length. However, there is a practical limit to how small the icons and labels can be made and still be recognizable to the user. It is often the case that all of the buttons (with or without text) that it is desired to display in a toolbar will not fit even at the smallest practical scale. A similar issue exists in the case of a global toolbar. A global toolbar is typically independent from an application window and may float over the application window, or be displayed outside the periphery of the window. The length of a global toolbar is at most as long as the width or height of the monitor screen, and may be restricted to an even shorter length. Accordingly, the same issues concerning not being able to include as many buttons as desired pertain to global toolbars as well.
Another toolbar issue arises when the size of an application window or global toolbar can be changed. In the case where the window is made smaller, the toolbars associated with the window typically shrink in length as well. In the case of a global toolbar, it is usually be resized directly. Either way the result is the same. Namely, the space available for existing buttons is reduced.
This same reduction in available toolbar space can also occur when a toolbar has been designed to maximize the space assuming a particular resolution. However, if the program containing the toolbar is run on a system having a lower resolution, more space would be needed for the same number of buttons. For example, current computer monitor resolutions range from 640xc3x97480 pixels to 1600xc3x971200 pixels, with 800-600 pixels being the most common resolution. If a toolbar is designed so the maximum number of buttons (with or without text) fit into the allotted space assuming a resolution of 800xc3x97600 pixels, they will not all fit in the allotted space when the program is run on a system employing a lower resolution such as the 640xc3x97480 pixels typical of many older computer monitors. Assuming that the buttons cannot be scaled down any further without becoming illegible, there is an issue as to what to do with the buttons that will no longer fit.
One attempt at addressing the foregoing space problems involved placing the labels below their associated icons in a horizontally oriented toolbar. While this creates more horizontal space, it reduces valuable vertical real estate on the computer monitor screen. Most monitor screens are wider than they are high. Thus, the loss of vertical viewing space to a toolbar is less desirable than taking up horizontal space. Additionally, in the case of a vertically oriented toolbar, placing the labels below the icons makes the situation worse.
Another attempt at resolving the toolbar resizing issue involved arbitrarily removing buttons from the toolbar in a right to left""sequence for a horizontally oriented toolbar. Presumably, the same procedure could be employed for vertically oriented toolbars by removing buttons in a bottom up sequence. In other words the rightmost (or bottommost) buttons are eliminated until the remaining buttons can fit in the downsized toolbar space. This method has obvious drawbacks. The primary advantage of a toolbar is to conveniently present the user access to a variety of functions and commands while the user is running the associated program. If buttons are removed from the toolbar during downsizing, the user must access the functions and commands associated with the eliminated buttons via other less convenient methods, such as by accessing a menu and selecting the function from a displayed list.
Still another attempt at dealing with the both the toolbar size restrictions and the downsizing issue involved a feature by which the inclusion of labels with the icons could be turned off. In other words, in one state the icons appeared with labels, and in the other state, no icon appeared with a label. While xe2x80x9cturning offxe2x80x9d the labels increases the number of icons that can be included in a tool bar and allows for the downsizing of the toolbar space without the loss of as many buttons, the advantages of having labels is lost. The labels, which are typically one or two words, provide a convenient way for the user to identify the function or state of the associated icon without having to memorize the appearance of the icon and the function it represents. Thus, removing all the labels reduces the usability of the toolbar.
Another issue with existing-toolbar designs involves a situation opposite that of the system resolution problem described earlier where a toolbar designed for a higher resolution system is viewed on a lower resolution system. In some cases, toolbars which have been designed to maximize the space assuming a particular lower resolution, will be viewed on a system having a higher resolution. The result is that all the buttons associated with the toolbar that would have filled the available toolbar space in the lower resolution system for which it was designed, will only fill a portion of the space when viewed on the higher resolution system. For example, FIG. 1A shows a tool bar employed in an older version of Microsoft Corporation""s Outlook Express(copyright) email program that was optimized for a resolution of 640xc3x97480 pixels. FIG. 1B shows this same toolbar displayed on a system having a resolution of 800xc3x97600 pixels. Notice the blank space to the right of the last button. Some users find this wasted space quite irritating, especially when it is realized that additional buttons cannot be added to this wasted space.
The present invention is directed toward a system and process that overcomes the problems of existing toolbar schemes by effectively dealing with the size limitations and changes in size of a toolbar, while maintaining as much of the convenience and usability attributed to a toolbar as possible. This is accomplished by creating a dynamically adjustable toolbar where labels and icons are added or removed based on an assigned priority in view of the space available for displaying the toolbar. The toolbar can be a horizontally oriented toolbar employing labels to the side of the icon or a vertically oriented toolbar employing labels underneath the icon.
Generally, the dynamically adjustable toolbar is generated and displayed by first identifying all the functions or commands that it is desired to include in a toolbar along with their respective button icons and labels (if there is one). A priority is then assigned to each label associated with a button and each icon associated with a button. It is noted that in the case of the icons, it does not matter if the icon has an associated label or not. If it has a label it is prioritized as if it did not. Next, the available toolbar space is determined. The button icons and labels are then displayed in the available toolbar space based on their assigned priority, with the icons and labels having the higher assigned priorities being displayed before those having lower priorities. In this way the toolbar button icons and labels that are deemed most important are displayed in the available toolbar space. Typically, this will mean that labels are the first to be eliminated from consideration for display in the available toolbar space since they would preferably be given a lower priority that the button icons. However, this need not be the case. In some circumstances, it might be deemed that the display of a label adjacent a button icon is more important that displaying some less important button. Thus, the label would be assigned a higher priority than the icon (and label if there is one) associated with the less important button. In this way, the less important button would be eliminated before the aforementioned label if the toolbar space is too limited to include both. Further, it is noted that the priority of a button""s icon is preferably made higher than its associated label to prevent a situation where the icon associated with the button is removed before the label. This will prevent confusion as to what icon is associated with a label and what needs to be selected to access the function.
There may also be circumstances where it is desired that if there is no room for a label associated with a particular button based on the assigned priorities, the entire button be eliminated rather than just the label. One way of ensuring that an icon and label associated with a toolbar button are displayed or eliminated together is to implement a shared priorities scheme. A shared priority is created by assigning the same priority to both the icon and label. The present system and process interprets the shared priorities as binding the affected elements such that they must be displayed together if there is room or neither is displayed if there is not room for both in the available toolbar space. Thus, the decision as to what is to be displayed in the available toolbar space would involve choosing among the icons, labels, and combinations of icons and/or labels that are tied together by a shared priority, and selecting the items based on their priority from highest to lowest until the available space is exhausted. It is further noted that the shared priority scheme could be expanded to include combinations of icons and/or labels that are not associated with the same toolbar button. In these cases, the elements having a shared priority could stand or fall together as described above, or another method could be used to determine which is eliminated from being displayed in the available toolbar space should there not be room for all of them. For example, the rightmost element having a shared priority in a horizontally oriented toolbar could be eliminated first. Similarly, the bottom-most element having a shared priority in a vertically oriented toolbar could be eliminated first.
The priorities assigned to each toolbar item (i.e., labels, icons, and combinations thereof) can be selected in a number of ways. For example, the priorities can be pre-assigned based on what is believed to be the order of importance and not subject to change. Alternately, a set of pre-assigned priorities would be initially implemented, but thereafter, the frequency of use of the various function and commands associated with the toolbar would be tracked. Conventional statistical methods would then be employed to dynamically re-prioritize the items associated with a toolbar based on the frequency of use data, thereby tailoring the toolbar priorities to the user. Finally, the priority scheme could be user-defined such that the priority of some or all the items would be designated by the user. In this last scenario, the program could initially employ the aforementioned pre-set priorities, and the user could change them as desired.
As can be imagined, once the priorities are assigned, the toolbar according to the present invention is completely dynamic. When it is initial displayed, the designated priorities determine which of the buttons with or without labels are included based on the available space. It does not matter what the computer system""s resolution is, as the maximum number of high priority buttons are included in any case. The only difference is that more elements are included if the resolution is higher. Further, any time the size of the toolbar changes for the reasons described earlier, the priorities can be used again to optimize the toolbar""s configuration. In the case where the toolbar space is increased, additional buttons, or labels for existing buttons, or both, are added to fill the additional space based on their assigned priority (i.e., highest first). If the toolbar space is reduced, buttons or labels associated with buttons are removedxe2x80x94again based on their priority. In this latter case, the lowest priority items are removed until the new reduced space is filled with the remaining higher priority items.